過去幾年,大家談 MLOps(Machine Learning Operations)時,重點都放在「如何讓機器學習模型可以產品化與維運」。 但隨著 GPT-4、LLaMA、Mistral 等大語言模型(Large Language Models, LLMs)的出現,我們發現:傳統的 MLOps 思維,已經不足以應付 LLM 的特性與挑戰。
於是,「LLMOps」這個詞開始流行,專門針對 LLM 的開發、部署與維運問題。
在傳統 MLOps 中,典型流程是:
挑戰點:
大語言模型跟傳統 ML 模型有幾個本質差異:
面向 | 傳統 ML 模型 | 大語言模型 (LLM) | 帶來的挑戰 |
---|---|---|---|
資料需求 | 小到中型資料集,自行蒐集/標註 | 使用網路大規模語料 (TB 級) | 開發者很難自行重新訓練 |
訓練方式 | 常常自行訓練或 fine-tune | 多數情況使用現成 API (OpenAI, Anthropic, HF) | 訓練變成「提示工程 / 輕量調整」 |
部署模式 | 部署在內部伺服器或雲端,自己維運 | 透過雲端 API 或本地大模型(推論資源昂貴) | 成本管理與 API 延遲更重要 |
監控 | 監控 Accuracy、Latency | 還要監控「幻覺率」「毒性」「合規」 | 評估更偏質化,難自動化 |
迭代方式 | Retrain + Deploy | Prompt / RAG / LoRA | 更快,但版本管理複雜 |
🔍 参考資料:
“From **MLOps to LLMOps: The evolution of automation for AI-powered applications”*(CircleCI,2024),指出,LLMOps 雖然沿用 MLOps 的基礎,但必須額外處理 治理、觀測性、成本控管、語言資料處理與即時響應,這也是為什麼需要新一套思維。
Prompt & Prompt Template 管理
RAG Pipeline 維運
觀測性 (Observability)
成本與資源控管
安全性與合規
假設公司要做一個「客服 FAQ 自動回覆系統」:
👉 特徵:資料量中等、可自己訓練、模型更新靠 retrain。
如果我們用 LLM(例如 GPT-4o-mini)來解這個問題:
不用訓練模型,直接丟 prompt:「你是客服助手,回答以下 FAQ 問題」。
為了避免「亂回答」,要加上 RAG Pipeline:
要做的維運工作是:
👉 特徵:不用自己訓練,但要處理 Prompt、資料、成本、輸出品質。
MLOps 解決的是「如何讓一個訓練好的模型持續運作」,痛點是「如何持續 retrain 模型」。
LLMOps 解決的是「如何讓一個巨大的、通常不是你訓練的模型,能在現實業務中 安全、便宜、穩定 地跑起來」,而痛點是「如何讓模型行為可控、可監控、可持續」。
換句話說:MLOps 解決模型壽命週期,LLMOps 解決模型「行為」的生命週期。
明天(Day02)我們要開始介紹這個系列的實作主線:「如何用 Free Tier + OpenAI API 打造一個企業知識庫 QA Chatbot」,並規劃我們的環境與工具組合。